Due to the high cost of memory in early computing systems or for convenience, date information has been and is still, stored in two-digit year formats. Information processing systems such as those used for accounting, inventory, and insurance, include numerous records containing date-related information. Large entities often design and maintain their own information processing systems, while smaller entities may purchase off-the-shelf software to perform their information processing. As the turn of the century approaches (defined herein as the year 2000), the information processing world is seeking solutions to avoid catastrophic failures that will result from existing applications that process date-dependent information with two-digit year formats.
Solutions have been suggested to combat the turn-of-the century problem. However, most of these solutions involve the conversion of all two-digit years to four-digit years. The drawbacks associated with such solutions are numerous. For example, all of the date fields in existing databases and flat files would require reformatting. Data definitions and internal work areas in application programs would also require reformatting. Similarly, all date-handling routines utilized by the application programs would need to be rewritten to accommodate four-digit year data. Thus most of the existing applications, whether custom designed or off-the-shelf will require substantial file reformatting and rewriting of routines at great expense in terms of cost and time. Moreover, those entities that rely on off-the-shelf products for information processing must rely on their vendors to implement such costly solutions before the turn of the century.
Consequently, a less onerous solution has been suggested in which the two-digit years are not converted to four-digit years. According to this solution, the application program code is modified so that each year that is read from the application's master file or other data files is reduced by 28 years. In this way all dates up to Dec. 31, 2027 are reduced back into the twentieth century and all of the date processing can occur in a single century. Once the program data is converted back in time and processed, the program data is increased by 28 years so that the resulting output dates reflect the actual or correct date.
A significant drawback associated with this solution is that it will still be necessary for a programmer to locate all of the points in the application program code where dates specified by the program data are input for processing or output after processing. At each of these points, code must be inserted to perform the date conversion. Thus each time the same date data is accessed it must be converted as program data by modified application code.
Accordingly, there still exists a need for a system and method for processing date-dependent data in a simple manner that does not require extensive programming changes to existing application software.